The present invention relates generally to object-based high level programming environments, and more particularly, to frameworks for loading and execution of portable, platform independent programming instructions within a virtual machine.
Recently, the Java™ programming environment has become quite popular. The Java™ programming language is an language that is designed to be portable enough to be executed on a wide range of computers ranging from small devices (e.g., pagers, cell phones and smart cards) up to supercomputers. Computer programs written in the Java™ programming language (and other languages) may be compiled into Java™ virtual machine instructions (typically referred to as Java™ bytecodes) that are suitable for execution by a Java™ virtual machine implementation.
The Java™ virtual machine is commonly implemented in software by means of an interpreter for the Java™ virtual machine instruction set but, in general, may be software, hardware, or both. A particular Java™ virtual machine implementation and corresponding support libraries, together constitute a Java™ runtime environment.
Computer programs in the Java™ programming language are arranged in one or more classes or interfaces (referred to herein jointly as classes or class files). Such programs are generally platform, i.e., hardware and operating system, independent. As such, these computer programs may be executed, unmodified, on any computer that is able to run an implementation of the Java™ runtime environment. A class written in the Java™ programming language is compiled to a particular binary format called the “class file format” that includes Java™ virtual machine instructions for the methods of a single class. In addition to the Java™ virtual machine instructions for the methods of a class, the class file format includes a significant amount of ancillary information that is associated with the class. The class file format (as well as the general operation of the Java™ virtual machine) is described in some detail in The Java™ Virtual Machine Specification by Tim Lindholm and Frank Yellin (ISBN 0-201-31006-6), which is hereby incorporated herein by reference.
Conventionally, when a class file is loaded into the virtual machine, the virtual machine essentially makes a copy of the class file for its internal use. The virtual machine's internal copy is sometimes referred to as an “internal class representation.” In conventional virtual machines, the internal class representation is typically almost an exact copy of the class file and it replicates the entire Constant Pool. This is true regardless of whether multiple classes loaded into the virtual machine reference the same method and thus replicate some (or much) of the same Constant Pool information. Such replication may, of course, result in an inefficient use of memory resources. In some circumstances (particularly in embedded systems which have limited memory resources) this inefficient use of memory resources can be a significant disadvantage.
As described in The Java™ Virtual Machine Specification, one of the structures of a standard class file is known as the “Constant Pool.” The Constant Pool is a data structure that has several uses. One of the uses of the Constant Pool that is relevant to the present invention is that the Constant Pool contains the information that is needed to resolve various Java™ Instructions, for example, a method invocation instruction that can be invoked by any of the methods within the class. FIG. 1A (which may be familiar to those skilled in the art) is a representation of a Constant Pool section of a class file that contains the information necessary to uniquely identify and locate a particular invoked method.
Additionally, conventional virtual machine interpreters decode and execute the virtual machine instructions (Java™ bytecodes) one instruction at a time during execution, e.g., “at runtime.” To execute a Java™ instruction, typically, several operations have to been performed to obtain the information that is necessary to execute the Java™ instruction. For example, to invoke a method referenced by a Java™ bytecode, the virtual machine must make several operations to access the Constant Pool simply to identify the information necessary to locate and access the invoked method.
To illustrate, FIG. 1B shows an exemplary conventional Java™ bytecode stream 150 including virtual machine instructions (typically referred to as Java™ bytecodes) that are suitable for execution by a conventional Java™ virtual machine. The first bytecode, Java™ bytecode 152 represents an arithmetic Java™ “Add” command with no associated parameters. The second bytecode, Java™ bytecode 154 represents a Java™ “iconst” instruction (load an integer constant on the stack). The Java™ bytecodes 156 and 157, CP-IndexA and CP-IndexB, respectively represent the first and second bytes of an index to the constant pool for the integer constant. It should be noted that Java™ bytecodes 152, 154 and 156 collectively represent a Java™ “iconst” instruction. In order to execute the Java™ Instruction iconst, at run time, an index to the Constant Pool is constructed from the CP-IndexA and CP-IndexA. Once an index to the Constant Pool has been determined, the appropriate structures in the Constant Pool have to be accessed so that the appropriate constant value can be determined. Accordingly, the Java™ instruction “iconstant” is executed but only after performing several operations at run time. As can be appreciated from the example above, the execution of a relatively simple instruction such as loading a constant value can take a significant amount of run time.
Furthermore, execution of relatively more complex Java™ instructions requires even more processing than noted above. For example, in order to conventionally execute an invoke method command 158, the constant pool has to be accessed several times at run time just to obtain the symbolic representation of information associated with the method. The CP—IndexC and CP—IndexD are indexes to a constant pool where information relating to the method including its parameter values needed for execution can be found. Accordingly, a CP—IndexD associated with the method instruction 158 is typically an index to an entry into the Constant Pool wherein that entry itself provides another pair of indexes to other entries in the Constant Pool, and so forth. Thus, execution of an invoke method command would require a significant amount of processing at run time (e.g., accessing the Constant Pool several times to obtain symbolic representation relating to the method). As will be appreciated, this conventional technique is an inefficient approach that may result in significantly longer execution times. In addition, once the symbolic information relating to the method has been obtained, there may be a need to convert the symbolic information into an internal representation at run time. Again, this is an inefficient approach.
Accordingly, there is a need for improved frameworks for loading and execution of portable, platform independent programming instructions within a virtual machine.